🤖 Kimi Code Review

Security Critical: Dependency Downgrades Detected

This PR migrates dependencies from leanMultisig to leanVM but introduces concerning downgrades that require immediate verification.

1. Critical: num-bigint Downgrade (Security Risk)

File: Cargo.lock (lines 4836, 4848)

The mt-field and mt-koala-bear crates now depend on num-bigint 0.3.3 instead of 0.4.6. This is a downgrade from a 2023/2024 release to a 2020 release.

• Risk: Version 0.3.3 may contain known vulnerabilities or bigint operation bugs that were fixed in 0.4.x
• Action: Verify if this downgrade is intentional for consensus compatibility or if this introduces security vulnerabilities in XMSS signature verification
• Impact: Affects all cryptographic operations using these field arithmetic crates

2. Repository Migration Verification Required

Files:

• Cargo.toml (line 15-16)
• crates/common/crypto/Cargo.toml (lines 15-17)

The source repository changes from leanEthereum/leanMultisig to leanEthereum/leanVM with commit 8fcbd779.

• Question: Is leanVM the legitimate successor repository to leanMultisig, or has the codebase been significantly refactored?
• Verification needed: Confirm that commit 8fcbd779 in leanVM corresponds to a reviewed, audited state of the XMSS signature verification logic
• Risk: If leanVM contains unaudited changes to the XMSS implementation, this could compromise signature verification correctness

3. Spin Crate Downgrade

File: Cargo.lock (lines 4877, 5533, 7359)

spin downgraded from 0.11.0 to 0.10.0 in multiple Plonky3 dependencies.

• While less critical than num-bigint, verify this doesn't introduce concurrency bugs in the prover/verifier setup

4. Plonky3 Commit Update

File: Cargo.lock (multiple entries)

Plonky3 dependencies updated from commit 2aeaa175 to 3f67d136.

• Verify this commit is from the official Plonky3 repository and doesn't introduce breaking changes to the polynomial commitment schemes used in consensus

5. Minor Issues

File: Cargo.toml (line 79)

• Trailing newline removed unnecessarily; keep file ending with newline per POSIX standard

File: crates/common/crypto/src/lib.rs (line 17)

• Comment update from "leanMultisig" to "leanVM" is correct, but ensure the LOG_INV_RATE: usize = 2 constant remains compatible with the new VM implementation

Recommendations

1. Block merging until the num-bigint downgrade is justified and security-impact assessed
2. Verify the leanVM repository is officially maintained by the leanEthereum organization and commit 8fcbd779 has been reviewed
3. Run the full consensus test suite against these dependency changes, particularly:
   • XMSS signature verification tests
   • State transition property tests
   • SSZ serialization roundtrips (affected by bigint operations)
4. Consider pinning num-bigint to 0.4.6 in your workspace if the downgrade is transitive and unintended

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

🤖 Claude Code Review

Here is the full review:

PR #408 Review: chore: bump leanVM to 8fcbd779 and leanSpec to latest main

This is a focused dependency bump with a clear, well-documented rationale. The overall approach is sound. A few things worth noting:

Correctness

The core alignment goal — pinning both LEAN_SPEC_COMMIT_HASH (30ffb6ca) and the leanVM rev (8fcbd779) so that fixtures and the client use the same prover/verifier — is exactly correct. Misalignment here would produce silent spec test failures or cross-client incompatibilities, so it's good to see both bumped in the same commit.

The p3-poseidon1 entry in Cargo.lock loses its p3-mds dependency at the new Plonky3 revision (3f67d136). p3-poseidon2 still depends on p3-mds. This looks like an upstream Plonky3 refactor (Poseidon1 no longer going through the MDS layer), not a regression, but it's worth confirming by skimming the leanVM changelog or Plonky3 commit history before merge, since Poseidon1 is used in the ZK proof stack.

Dependency version notes

The lock file now contains two coexisting versions of num-bigint: 0.3.3 (used by the mt-* crates from leanVM) and 0.4.6 (used by p3-field and p3-monty-31 from Plonky3). Cargo handles this correctly, but it's worth being aware of for auditing purposes — any code that passes num_bigint::BigUint across the leanVM ↔ Plonky3 boundary will not compile, providing a compile-time safety net.

getrandom is downgraded from 0.4.2 to 0.3.4 for the tempfile crate. This crate is not in any critical path (test/temp file handling only), and getrandom 0.3.x is maintained and secure, so this is fine.

spin downgraded from 0.11.0 to 0.10.0 for p3-dft and p3-monty-31 is expected and correct given the Plonky3 pin.

windows-sys unified to 0.61.2 across the board — routine.

Stable-Rust build fix

Pinning Plonky3 to 3f67d136 to avoid the maybe_uninit_slice nightly feature is the right call. The PR description explains the exact mechanism clearly, and this avoids any CI instability from a floating HEAD.

Minor

The trailing newline removal in Cargo.toml is a no-op but keeps the file tidy.

The comment update in lib.rs (leanMultisig devnet5 → leanVM devnet5) is correct.

What to verify before merge

• Confirm that leanSpec commit 30ffb6ca does indeed pull lean-multisig-py v0.0.6, which corresponds to leanVM 8fcbd779. The PR asserts this but does not include a direct reference — a quick check of leanSpec/requirements.txt or equivalent at that commit would close the loop.
• Optionally, verify the p3-poseidon1 / p3-mds decoupling at Plonky3 3f67d136 is intentional upstream (it is, based on Plonky3 history, but worth noting for auditors).

Summary

The change is correct and well-scoped. The pinning strategy (matching leanVM rev to what leanSpec uses, pinning Plonky3 to avoid nightly requirements) is the right approach. No correctness or security issues found.

Automated review by Claude (Anthropic) · sonnet · custom prompt

🤖 Codex Code Review

Findings

1. crates/common/crypto/Cargo.toml:15-17
   This PR swaps the consensus-critical XMSS aggregate verifier/prover from leanMultisig.git to leanVM.git at a new revision. In ethlambda, block acceptance is effectively delegated to that upstream code through verify_block_signatures and verify_type_2 (crates/blockchain/src/store.rs:831). That means any semantic change in proof binding, deserialization, or verification now changes local fork-choice inputs and block validity, even though no in-tree consensus logic changed. I’d treat this as blocking unless the upstream delta is audited or vendored and you add compatibility vectors showing previously valid proofs still verify and malformed/invalid proofs are still rejected.

2. Makefile:27-35 with crates/blockchain/tests/signature_spectests.rs:14-20 and crates/blockchain/tests/signature_spectests.rs:98
   Bumping the leanSpec commit in the same PR weakens the only end-to-end oracle for this verifier swap. Those tests consume fixtures generated from leanSpec; if the fixture generator and verifier semantics move together, the suite can remain green while ethlambda silently diverges from peers still on the previous proof semantics. For consensus code, keep at least one fixed corpus from the prior commit, or add explicit cross-version compatibility tests, so this change is validated against an independent baseline.

No direct local Rust/style issues stood out beyond those two concerns.

I couldn’t run cargo test here because the sandbox blocks writes to Cargo’s git cache, and this PR requires fetching the new leanVM git dependency.

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

Greptile Summary

This PR bumps the lean-multisig/leanVM dependency and leanSpec commit hash to align the prover/verifier revision used by this client with the one locked by the Python test fixtures (lean-multisig-py v0.0.6), and pins transitive Plonky3 to 3f67d136 to unblock builds on stable Rust.

• Updates all leanEthereum/leanMultisig.git references to the renamed leanEthereum/leanVM.git at rev 8fcbd779, and bumps LEAN_SPEC_COMMIT_HASH in the Makefile to leanSpec main 30ffb6ca (2026-06-03).
• Pins Plonky3 to 3f67d136c71bec40f180c85d0bb2b654acddef22 to avoid the unstable maybe_uninit_slice feature present in the previously-resolved HEAD; this cascades to spin 0.10.0, num-bigint 0.3.3 (mt-* crates), and getrandom 0.3.4 for tempfile in the lockfile.
• Comment in crates/common/crypto/src/lib.rs updated to reflect the upstream repo rename.

Confidence Score: 5/5

Safe to merge — all changes are dependency version pins with no logic modifications.

The PR makes no changes to application logic, only updates dependency sources and commit hashes. The Cargo.lock reflects exactly what the description promises: leanVM repo rename, Plonky3 stable-Rust pin, and cascading transitive updates. The Makefile hash bump aligns leanSpec with the same prover/verifier revision, which is the intended pairing.

No files require special attention. The Cargo.lock is the most complex file but all changes are machine-generated and consistent with the declared intent.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["crates/common/crypto/Cargo.toml"] -->|"lean-multisig @ 8fcbd779"| B["leanEthereum/leanVM.git"]
    A -->|"leansig_wrapper @ 8fcbd779"| B
    B -->|"transitive dep"| C["Plonky3 @ 3f67d136\n(stable Rust compatible)"]
    C -->|"uses"| D["spin 0.10.0"]
    C -->|"uses"| E["num-bigint 0.3.3\n(mt-field, mt-koala-bear)"]
    F["Makefile\nLEAN_SPEC_COMMIT_HASH"] -->|"30ffb6ca (2026-06-03)"| G["leanEthereum/leanSpec\n(lean-multisig-py v0.0.6)"]
    G -.->|"locks same prover/verifier rev"| B

_{Reviews (1): Last reviewed commit: "chore: bump leanSpec pin to latest main ..." | Re-trigger Greptile}